Implement SVG text-decoration - underline, strikethrough, etc.

Tried editing the inline CSS manually to no effect. Surprised it's not requested more as Inkscape is often used to do website mock-ups.

I agree. It seems a bit shocking to me that you can't even add underlines with CSS in the XML editor.

People probably wind up drawing lines under the text (which is frustrating, especially when the text is edited) or just ignoring the lack of lines. (At least that's what I've done before in the past.)

Agreed, this feature is expected by almost anyone who works with the text tool.

If you are implementing this feature, please pay close attention to corner cases like text along path and font-weight when implementing the drawing method.

I support this request too, it would be a very useful feature.

+1

Given the maturity of the software and the number of supported features, I find it very surprisingly that this control is still lacking. In my opition it should be given high priority and be included as part of one of the next milestones.

I totally agree. This is the main reason why I still revert to CorelDraw for some uses, it is very annoying to have to draw a line everytime I want to underline some text. This feature is usually supported by every software that allows text formatting (as with bold and italic).

+1

Yes please!

Still no news on this wish item? It's kind of a killer feature for not switching to inkscape.

I am creating an SVG template with UI widgets for web mockups - it would be great to be able to add underline without having to literally draw a line underneath the text.

Is there a reason documented somewhere as to why this hasn't been implemented? Seems that SVG supports it, and there are use cases for it. Is there a technical barrier to implementation?

This feature is a must! Come on.. This is not a "wishlist" thing. You loose tons of users on this. So annoying..

Adding my comment to try and raise the level of priority for this feature... Yes this is much more than a "wishlist" feature, it is an absolutely basic and essential function for any text or graphic editor. It is amazing that Inkscape supports so many advanced features but omits this most basic one.

The attached patch implements display of text decorations. It does not implement setting them within Inkscape - they must already be present in the SVG. Maybe they will "take" if the XML is edited, but that has not been tested extensively.

Known issues:

1. Some fonts, for whatever reason, cause the text decoration to not be set in the style. On my Linux box "Courier New" does this. When this happens selecting the text and changing to another font, like "Arial", causes the decorations to appear. Since the patch doesn't even look at font names this issue was probably present in the code before, just not visible because no text decorations were present.

2. Some bits and pieces of the next generation SVG text decoration have been edited in, since I was in there anyway, but none of that has been fully implemented yet. So no dots, dashes, wavy lines, or colors (different from the text) yet.

3. Currently "Blink" is drawn as a double strikethrough. It was a toss up for me between showing that the decoration was set and just ignoring it. At least while this is still experimental I think it is better to show some indication when that is on. Perhaps better to not show anything when it is off.

4. What does "_drawing.outline()" do in _renderItem in drawing-text.cpp? I did not have any SVG that triggered it. If it is set
the decorations will not be shown since that case has its own return. If somebody sends me an example I will fix this.

Examples with text decoration and the font bug will be posted next.

This example shows the problem with Courier New - the text is underlined, but it is not shown that way. Changing to Arial
(or many other fonts) resolves this.

This example shows text decorations.

I just remembered one other issue, which is outside my code. In theory it looks like SVG supports setting more than one text decoration. However, when that is done in the SVG (as in the "all" line here) none of the corresponding bits are set in the Style.

Re: 14

-Perhaps better to not show anything when it is off.

+Perhaps in the final release better to not show anything when blink is set.

Also I forgot to thank Krzysztof for guiding me through some of the trickier sections of Cairo. Without that help I would still
be trying to figure out why rectangles generate an XOR pattern when written over glyphs.

There is an issue when this patch is built on Windows where whatever code is setting the underline, overline etc. bits is very, very, iffy. Sometimes it sets the bits properly, sometimes it doesn't. (It never sets extra bits, it just does not set some that should be set.) That happens well before the changes in this patch kick in. Will try to hunt it down. Not an issue on linux, the bits set reliably there, except with respect to when certain fonts are used, sigh.

David: Great to see progress on this front! I did a quick check with your patch and test files.

Is there a reason that overline is a different line height than underline or line-through? In opening that main test file in Chrome & Opera, the lines are all visually the same.

On a related note, it appears that for certain fonts the line heights of the decorations change, something not observed opening the same file in Chrome or Opera. A good example font is Angelina http://www.dafont.com/angelina.font and the decorations become pretty thin.

One more thing, in addition to certain fonts not showing decorations, it seems like it's also pretty common to get it to wonk out on a font that works when you change the Font style.

Re: 19

Overline height is my mistake. Setting the draw for overline at the top of the ascender was too high. I was lowering the bottom until it looked right, but forgot to lower the top too. If you want to temporarily fix yours change drawing-text.cpp line 178 from

            Geom::Point(0.0, tsp_asc_adj -_nrstyle.underline_position),

to

            Geom::Point(0.0, tsp_asc_adj -_nrstyle.underline_position + 1 * _nrstyle.underline_thickness);

This position is not specified by any font, or at least not in a way that Freetype2 can return it, so we have to punt.

The thickness is read from the font. If the font specifies really thin, that's what we get. If the font is corrupt and specifies something ridiculous, we get that too. An alternative would be to make the width something like (ascender + descender)/20, or use values like that to set upper and lower limits for line thickness.

Agreed that parts of this code are not very solid. I need to run it in valgrind, some of this may be due to uninitialized variables, which it might catch. Unfortunately that is not an option on WIndows, and it is much less well behaved there than on Linux.

Just obtained some Hebrew SVG's to test this section, odds are R->L text will have the line drawn in completely the wrong place now. (Hebrew does not work very well in Inkscape in any case, the problem is not the pure R->L parts, but the embedded L-R sections, for instance, number strings. Some of those sections it is really hard to even select the text you want to change, the cursor dances around like it has a mind of its own. Unadulterated Hebrew also blows up parts of my EMF output code pretty severely, for instance, the first character, which should be all the way at the right end of a text fragment, ends up drawn all the way at the left!)

This patch replaces the preceding one. It corrects the issues in sp_style_read_itextdecoration() in style.cpp which were
responsible for the general flakiness concerning whether or not the text-decoration was applied. (It was an off by one offset problem, so that instead of looking where it thought it was for the \0 terminator on a C string it was looking one byte past that, consequently all sorts of external events were changing the results.)

Found this with valgrind. There are two other uninitialized variable problems that are being uncovered by the text-decoration code, but those are in optional.hpp, and that seems not be part of Inkscape. Transient file?

Really? 6 years and no resolution?

SVG text decorations are fully implemented (I believe) in branch lp988601. It is most likely hopeless broken on T->B languages, I'm not even sure what "underline" means in that context. While working on that several other problems were encountered and cleaned up, for instance making text decorations and spacing work in a R->L language. All of that testing was done with Hebrew, hopefully the changes will also work for Arabic and the others.

See also bugs #1169348, #1180785, and #1181362.

Yes, lp988601 needs to be merged back into trunk.

With the latest set of patches in lp988601, which as this is written, are in the process of being merged back into trunk,
the SVG example from #24 renders as shown in this screen shot. The decorations in my system stick to the text appropriately on rotation or translation.

At present no control has been added to allow interactive editing of the text decorations - the example was made by hand editing the SVG.

Has there been any progress in the past 14 months? The current version of inkscape still has no GUI controls for adding underlined or strike-threw text and at least my (somewhat unmotivated) tries to edit the svg file via text editor also showed no results in inkscape...

There were a bunch of changes to the style code a while back and they broke the text decoration and the rudimentary GUI I had written to set those values. I thought I had reentered the display sections into trunk, but had definitely not submitted the GUI stuff. Will check when I get a chance. Note that the way the GUI broke was that in some instances a section of selected text would be designated to be underlined, for instance, but the "apply" would not take. It would generally work if the entire word was selected. In any case, too iffy to put into trunk like that.

I'm posting the rudimentary GUI so that people can experiment with this if they want. It works with rev 13647 of trunk and it is BUGGY.

There are several things to be aware of:

1. shift-control-t to bring up the text and font pane, which will now have a 3rd tab "Decorate".

2. Text decoration is different for CSS 2 and 3, and as I understand it, it is not yet finalized for CSS 3. The GUI lets
you select which of those modes to use. For CSS 2 only the "Action" and "Line" rows are active, for CSS 3 they all
are. I suspect that much of the bugginess comes from confusion elsewhere in inkscape where it has to deal with
both of these specifications.

3. For CSS 2 the GUI does not let you set the color of the text decoration different from that of the text. So no
red strike through on black text. (It is possible to do this by hand editing and nesting style changes, the GUI doesn't support
that though.)

4. Known bug(s) - somewhere in Inkscape, not necessarily in this code: Internal spans cannot be unset or set to inherit ever, and cannot be reformatted reliably in CSS 2. In CSS 2 mode once a text span has been set, or reset, or looked at sideways, it cannot be set again. Example actions to demonstrate:
  enter text: 1234567890
  highlight: 23456789
  select: CSS=2, underline, click APPLY
  highlight: 345678
  select: CSS=2, overline, click APPLY
  RESULT - nothing happens, EXPECTED overline on 345678
  select:CSS=3, overline, click APPLY
  RESULT == EXPECTED == overline on 345678
  select:CSS=(either), (X or ?), click APPLY
  RESULT - nothing happens, EXPECTED: for X it should clear, for ? it should take the decoration of the
     surrounding span

5. The attached patch has DEBUG lines in it, which log to the console the operation which was just ordered (but which
may not have actually done anything, see preceding).

Anybody who wants to clean up these bugs, please have at it.

Please continue any threads about an editor for text decorations in bug #1269206.
When problems are found in the existing text decoration rendering, please post that as a new bug.

Would love to see this implemented in the next 0.93 release. +1

Closing because this bug seems to have run it's course; the feature was either developed and submitted or moved into a design report. This should likely be a Merge Request thread in the new GitLab repository.

Closed by: https://gitlab.com/doctormo